Systems and devices for mobile payment acceptance

ABSTRACT

A mobile device may provide payment acceptance for purchases, payments and/or money transfers by accepting payment information from a powered, or a non-powered, card using a contactless communication channel formed between the card and the mobile device. The payment information may be communicated by the mobile device to network entities that may be used to settle such purchase, payment and/or money transfer transactions. The mobile device may, for example, accept more than one payment account to split a purchase among several payment accounts. A user of a mobile device may, for example, store payment information within the mobile device for future purchases. A user of a mobile device may, for example, request checkout options using the mobile device, such as customizing receipt delivery, annotating receipts with comments and categorizing purchases for customized accounting reports.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication Nos. 61/484,547, titled “SYSTEMS AND DEVICES FOR MOBILEPAYMENT ACCEPTANCE,” filed May 10, 2011 (Attorney Docket No. D/063PROV), 61/484,566, titled “SYSTEMS AND METHODS FOR A MOBILE ELECTRONICWALLET,” filed May 10, 2011 (Attorney Docket No. D/064 PROV),61/484,576, titled “SYSTEMS AND METHODS FOR MOBILE AUTHORIZATIONS,”filed May 10, 2011 (Attorney Docket No. D/065 PROV), and 61/484,588,titled “SYSTEMS AND METHODS FOR CONTACTLESS COMMUNICATION MECHANISMS FORCARDS AND MOBILE DEVICES,” filed May 10, 2011 (Attorney Docket No. D/066PROV) all of which are hereby incorporated by reference herein in theirentirety.

BACKGROUND OF THE INVENTION

This invention relates to mobile devices and related systems.

SUMMARY OF THE INVENTION

A mobile device is provided that may be used as a point-of-saleterminal. A contactless communication channel may, for example, beformed between the mobile device and a payment card to communicatepayment information from the payment card to the mobile device. Themobile device may, for example, use the communicated payment informationto complete a purchase transaction that may be initiated by the mobiledevice. Accordingly, for example, no payment information need reside onthe mobile terminal to complete a payment transaction. Instead, anapplication may be remotely activated, or a user of a mobile device mayactivate an application on the mobile device, that allows the mobiledevice to accept payment information directly from a payment card beforeand/or during a payment transaction.

A mobile device may, for example, provide a browsing activity wheregoods and/or services may be located for purchase on a website (e.g., anAmazon or eBay website). An application may, for example, be executed ona mobile device that may communicate with a checkout application runningon a website. Payment information may be exchanged directly from auser's payment card to the checkout application using the user's mobiledevice. In so doing, for example, a mobile device may be used as acontactless payment acceptance terminal.

A user may be provided an option of storing payment informationassociated with a payment card within a memory of the mobile device.Accordingly, for example, a mobile device may store payment informationassociated with one or more payment accounts. In so doing, for example,a mobile device may store multiple payment accounts that may be recalledfrom a memory of the mobile device at the user's request to complete apayment transaction.

A mobile device may detect the presence of a card that is brought withina communication distance of a contactless interface of the mobiledevice. For example, a card having RFID capability may communicate withan RFID device of a mobile device when the card comes within a distance(e.g., up to 2 inches) of the mobile device. Accordingly, for example, acard type (e.g., a powered card or a non-powered card) may be identifiedby the mobile device.

A non-powered card may, for example, communicate one, two, and/or threetracks of magnetic stripe data to a mobile device via a contactlessinterface of the mobile device. Accordingly, a processor of a mobiledevice may identify an account type (e.g., credit or debit) that may beassociated with the non-powered card by inspection of magnetic stripedata (e.g., account number) received from the non-powered card.

A powered card may, for example, communicate information (e.g.,information within discretionary data fields) to a contactless interfaceof a mobile device. In so doing, for example, the additional informationmay be analyzed by a processor of the mobile device to determine that adetected card is a powered card having increased capability.Accordingly, for example, a user of a powered card may select a feature(e.g., pay with credit) on the powered card and a processor of a mobiledevice may detect that such a feature is selected based upon an analysisof information (e.g., discretionary data) received from the poweredcard.

A mobile device may validate a payment card. For example, a mobiledevice may request entry of a PIN after a payment card is presented tothe mobile device and payment information is communicated to the mobiledevice by the payment card. Once entered, a mobile device may, forexample, access a server associated with the payment card's issuingentity to validate the PIN. Alternately, for example, a processor of amobile device may compare the PIN entry against local memory contents ofthe mobile device to validate the entered PIN.

As per another example, a mobile device may validate a payment card byrequiring that the physical payment card be present during a paymenttransaction. Accordingly, for example, a mobile device may require thata physical payment card be tapped against the mobile device so that acontactless communication channel may be formed between the payment cardand the mobile device to verify the identity of the payment card.Accordingly, for example, identifying information communicated by thepayment card to the mobile device may be compared against informationpreviously stored within a memory of the mobile device that may beassociated with the payment card.

One or more payment cards may, for example, be presented to a mobiledevice to complete a purchase transaction. Accordingly, for example,split-payment options may be offered by a mobile device. In so doing,for example, a first payment card may be tapped against a mobile deviceand accepted by the mobile device as a first form of partial payment, asecond payment card may be tapped against a mobile device and acceptedby the mobile device as a second form of partial payment, and so on. Amobile device may, for example, allow a user to select an amount foreach partial payment and may settle each partial payment amount witheach respective issuer of each payment card presented for partialpayment.

A mobile device may provide checkout options to a user. For example, amobile device may allow a user to associate purchase categories (e.g.,groceries, auto repair, or entertainment) to purchases transacted by themobile device so that the user may prepare a more detailed accounting ofhis or her expenditures. As per another example, a rewards card may betapped against a mobile device so that rewards card information may becredited with purchases transacted by the mobile device.

A mobile device may provide receipt delivery options to a user. Forexample, a mobile device may allow a user to select one of many receiptdelivery options (e.g., text messaging, email or autonomous delivery toaccounting software executed by a processor of the mobile device). Otherreceipt options may be provided by a mobile device in a graphical format(e.g., a barcode) so that proof-of-purchase may be verified by a reader(e.g., a barcode reader).

Money transfers may, for example, be transacted by a mobile device. Oneor more payment accounts (e.g., a car account or a utility account) maybe selected by a user of a mobile device to receive a payment transactedby the mobile device. Payment information may be recalled from memoryand/or entered by a user of the mobile device and then communicated tonetwork entities by the mobile device to complete payment transactions.

Person to person transfers may, for example, be transacted by a mobiledevice. A user of a mobile device may, for example, tap a payment cardagainst the mobile device to communicate source account information tothe mobile device where funds are to be withdrawn. A person receiving atransfer of funds may, for example, tap his or her payment card againsta device (e.g., a mobile device) to communicate target accountinformation where funds are to be deposited. A mobile device may, forexample, gather source and target account information and communicatesuch information to network entities to complete the funds transfertransaction.

A mobile device may, for example, provide a scanning capability (e.g.,via a camera) to scan images (e.g., barcodes) that may be analyzed by aprocessor of the mobile device. Accordingly, for example, a mobiledevice may be used to scan product information from a product tag (e.g.,a barcode) to select an item for purchase. As items are selected forpurchase, scanned information is processed and displayed by the mobiledevice to produce a summary of items that may be selected for purchase.The mobile device may, for example, collect payment information from apayment card via a contactless communication channel and then use thepayment information to complete a purchase transaction for the itemsscanned by the mobile device.

A mobile device may access electronic billing information via one ormore communication capabilities of the mobile device. A merchant (e.g.,a restaurant) may provide access to an electronic tab generated by themerchant (e.g., a bill generated by a restaurant for a dinner for two).Items billed by the merchant may be accessed by a user of a mobiledevice and displayed by the mobile device to produce a summary of itemsbilled. The mobile device may, for example, collect payment informationfrom a payment card via a contactless communication channel and then usethe payment information to complete a purchase transaction for thebilled items.

Any mobile device, such as a laptop computer, a mobile telephonic device(e.g., a cellular phone), a PDA, an MP3 player, or a positioning device(e.g., a GPS) may be a point-of-sale terminal. Accordingly, for example,a mobile device may accept payment information from any payment card,communicate such payment information via a network, complete asettlement process with network entities (e.g., an issuer or a paymentserver) on such a network, and provide results (e.g., an electronicreceipt) of the completed purchase transaction to a user of the mobiledevice.

A mobile device may include a contactless communication device.Accordingly, for example, a mobile device may communicate with any cardhaving contactless communication capability. For example, a card (e.g.,a non-powered card) may include a near-field communication device (e.g.,an RFID tag) that may communicate with a contactless communicationdevice of a mobile device to form a two-way communication channelbetween the card and the mobile device. In so doing, for example, anon-powered card may communicate one, two, and/or three tracks ofmagnetic stripe information to a mobile device before and/or during apurchase transaction conducted by the mobile device.

A card (e.g., a powered card) may include a near-field communicationdevice (e.g., an RFID) that may communicate with a contactlesscommunication device of a mobile device. A powered card may, forexample, include a battery, a processor, memory, and a manual inputinterface (e.g., one or more buttons) that may allow a user of thepowered card to programmably communicate information to a mobile device.For example, a powered payment card may include a feature associatedwith a button that allows a user to, for example, pay with credit or paywith debit. Accordingly, for example, a powered payment card maycommunicate such a payment selection within discretionary data fields ofone or more tracks of magnetic stripe data.

A powered card may, for example, include circuitry to simulate touch(e.g., a capacitance change) in order to form a contactlesscommunication channel with a mobile device. Accordingly, for example, apowered card may be pressed against a touch-sensitive display of amobile device and information may be communicated by the powered card tothe mobile device through a series of card-simulated touches that may bedetected by the touch-sensitive display of the mobile device andprocessed by a processor of the mobile device as data communicated bythe powered card.

A powered card may, for example, include a light sensor to form acontactless communication channel with a mobile device. Accordingly, forexample, a powered card may be pressed against a display of a mobiledevice and information may be communicated from the mobile device to thepowered card through a series of light pulses generated by the displayof the mobile device. A frequency, pulse width, and/or a pulse intensityof light pulses may, for example, be detected by a processor of apowered card as data communicated by a mobile device.

A powered card may, for example, include a light source (e.g., an LED)to form a contactless communication channel with a mobile device.

Accordingly, for example, a powered card may emit varying light pulsesfrom an LED that may be detected by a motion-capture device (e.g., acamera) of a mobile device as data communicated by the powered card. Apowered card may, for example, include sound emission capabilities thatmay be detected by a microphone of a mobile device as data communicatedby the powered card through a contactless communication channel. Amobile device may, for example, include sound emission capabilities thatmay be detected by a microphone of a powered card as data communicatedby the mobile device through a contactless communication channel.

BRIEF DESCRIPTION OF THE DRAWINGS

The principles and advantages of the present invention can be moreclearly understood from the following detailed description considered inconjunction with the following drawings, in which the same referencenumerals denote the same structural elements throughout, and in which:

FIG. 1 is an illustration of a mobile devices constructed in accordancewith the principles of the present invention;

FIG. 2 is an illustration of a network topology constructed inaccordance with the principles of the present invention;

FIG. 3 is an illustration of a mobile payment system constructed inaccordance with the principles of the present invention;

FIG. 4 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 5 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 6 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 7 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 8 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 9 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 10 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 11 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 12 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 13 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 14 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 15 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 16 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 17 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 18 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 19 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 20 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 21 is an illustration of a display screen constructed in accordancewith the principles of the present invention;

FIG. 22 is an illustration of a mobile funds transfer system constructedin accordance with the principles of the present invention;

FIG. 23 is an illustration of a mobile payment system constructed inaccordance with the principles of the present invention;

FIG. 24 is an illustration of a mobile payment system constructed inaccordance with the principles of the present invention;

FIG. 25 is an illustration of a mobile payment system constructed inaccordance with the principles of the present invention; and

FIG. 26 is a flow chart of processes constructed in accordance with theprinciples of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows mobile device 100. Mobile device 100 may be any mobiledevice, such as a mobile telephonic device (e.g., cell phone), a PDA, anelectronic tablet, an MP3 player, or a locating device (e.g., a GPSdevice). Accordingly, mobile device 100 may be operated in a mobileenvironment while a user of mobile device 100 goes about his or herdaily activities (e.g., driving, shopping, walking, dining, andexercising). In addition, for example, mobile device 100 may performmultiple functions simultaneously (e.g., a person may carry on aconversation while at the same time browsing and purchasing products onthe Internet).

Mobile device 100 may include audio processing devices (e.g., microphone108 and speaker 110). Accordingly, for example, mobile device 100 mayreceive voice commands from a user via microphone 108 and may processsuch commands to perform a function. For example, a user may placemobile device 100 into a desired operational mode by speaking a commandinto microphone 108 that is associated with the desired operationalmode. In so doing, for example, mobile device 100 may engage inhands-free operation by receiving voice commands via microphone 108 andperforming functions associated with the received voice commands.

Mobile device 100 may receive data input via microphone 108. Forexample, a voice-band modem may generate signals in a voice-bandfrequency range that may be received by microphone 108. A processor ofmobile device 100 may interpret the received audible information as datasignals and may process the data signals as, for example, data valuesand/or control data input.

Mobile device 100 may include camera 102. Camera 102 may capture one ormore frames of video data and store the video data within a memory ofmobile device 100. Accordingly, for example, a processor of mobiledevice 100 may receive one or more frames of video information viacamera 102 and may process the video information as data values and/orcontrol data input. In so doing, for example, mobile device 100 mayreceive optical information that is sensed by camera 102 during a seriesof one or more video capture events that produce one or more frames ofvideo information. The one or more frames of video information maycontain one or more data elements (e.g., pixels) having properties(e.g., color, intensity, or contrast) that may be interpreted by aprocessor of mobile device 100 as data values and/or control data.

Mobile device 100 may include manual input interface 112. Manual inputinterface 112 may, for example, include keys and/or buttons that may besensitive to manual input, such as a touch or an application ofpressure. Accordingly, for example, a user of mobile device 100 mayenter information into mobile device 100 via manual interface 112 tocause a processor of mobile device 100 to enter a particular mode ofoperation. Manual interface 112 may, for example, be used for data entry(e.g., dialing a phone number or entering data as may be requested bymobile device 100) during a particular mode of operation of mobiledevice 100.

Mobile device 100 may include display 104. Display 104 may providevisible information that may be utilized by a user during interactionwith mobile device 100. A portion or all of display 104 may be touchsensitive such that objects making contact with display 104 or objectscoming within a proximity of display 104 may be detected by a processorof mobile device 100. Accordingly, for example, mobile payment graphicaluser interface 106 may be provided by display 104 so that graphicalinformation may be displayed to solicit and/or receive data entry from auser. In so doing, for example, touch-sensitive graphical user interfacedevices such as radio buttons, textual input boxes, virtual buttons,pull-down menus, and navigational tools may be used for data entry toinitiate, change, and/or support functions performed by mobile device100.

FIG. 1 shows architecture 150. User interface 152 may, for example, beincluded within architecture 150 to allow user interaction witharchitecture 150. For example, a dedicated key pad or keyboard may beincluded within user interface 152 to allow alphanumeric data entry intoarchitecture 150.

Architecture 150 may include one or more displays 154. Display 154 may,for example, be touch-sensitive. Accordingly, for example, display 154may be utilized for alphanumeric data entry using virtual buttons thatmay be rendered onto touch-sensitive portions of display 154. In sodoing, for example, touching virtual buttons that may be associated withalphabetic and numeric characters of display 154 may be detected byprocessor 158 as alphanumeric data entry.

Alphanumeric entry boxes may, for example, be rendered onto display 154.A user may, for example, activate a cursor within such an alphanumericentry box by touching an area within the alphanumeric entry box. A usermay utilize user interface 152 and/or a virtual keypad rendered ontodisplay 154 to select alphanumeric characters to be placed within thealphanumeric entry box in accordance with a character positionidentified by an activated cursor within the alphanumeric entry box. Inso doing, for example, processor 158 may receive alphanumeric charactersas typed into a alphanumeric entry box of display 154 and may use suchalphanumeric characters as data input.

Display 154 may, for example, provide data output from architecture 150.For example, display 154 may communicate data using a series of lightpulses. Accordingly, for example, processor 158 may cause one or moreportions of display 154 to produce light pulses having varyingcharacteristics (e.g., duration, intensity, and frequency) that maycommunicate information via such light pulses. In so doing, for example,a device that may be sensitive to light pulses may receive informationcommunicated by display 154 via light pulses having varyingcharacteristics. Display 154 may, for example, communicate data usingvisual information that may be substantially static (e.g., a barcode).

Architecture 150 may include one or more transceivers 156. Transceiver156 may communicate information to and/or may receive information fromone or more devices. Transceiver 156 may, for example, communicate via awireless interface with one or more cellular stations of a mobilenetwork. Accordingly, for example, transceiver 156 may allow a mobiledevice (e.g., mobile device 100 of FIG. 1) to establish a communicationschannel with an associated cellular station. In so doing, for example, amobile device (e.g., mobile device 100 of FIG. 1) may exchangeinformation (e.g., voice, text, data, or multimedia) with one or moreterrestrial networks (e.g., the internet or a payment network) via anassociated cellular station. As per another example, transceiver 156 mayexchange information with one or more other mobile devices via one ormore associated cellular stations.

Transceiver 156 may, for example, communicate via a wireless interfacewith one or more mobile devices directly. Accordingly, for example,transceiver 156 may communicate with another mobile device without firstaccessing a mobile network via a cellular station of the mobile network.As per another example, transceiver 156 may, for example, communicatevia a wireless interface with one or more network devices (e.g., awireless access point) directly. Accordingly, for example, a mobiledevice (e.g., mobile device 100 of FIG. 1) may directly connect to awired and/or a wireless network via any one or more wireless standards(e.g., Bluetooth or Wi-Fi) to exchange information with other devicesthat may be connected to the wired and/or wireless network. In so doing,for example, a wired and/or wireless network may be accessed by a mobiledevice without first accessing a mobile network via a cellular stationof a mobile network.

Architecture 150 may include contactless communication device 162, whichmay communicate via any one or more contactless communicationmethodologies, such as for example, near field communications (e.g.,RFID), Bluetooth, touch simulation, light pulsing (e.g., via an LED),and electromagnetic data communication (e.g., via a dynamic magneticstripe communications device). Accordingly, for example, contactlesscommunication device 162 may be compatible with any contactless device,such as for example, an RFID enabled payment card and a contactlessreader (e.g., a magnetic stripe reader or an NFC reader).

A non-powered card may, for example, communicate with contactlesscommunications device 162. Contactless communication device 162 may, forexample, establish a carrier field (e.g., an RF field) that may bemodulated by a device (e.g., an RFID tag) of a non-powered payment card.In so doing, for example, an RFID tag of a non-powered payment card mayderive operational power from an RF field provided by contactlesscommunications device 162 and may communicate information (e.g., one,two, and/or three tracks of magnetic stripe data) to contactlesscommunication device 162 by modulating the RF field produced bycontactless communications device 162.

A powered card may, for example, communicate with contactlesscommunication device 162. A powered card may, for example, include aprocessor, a battery, a memory, wireless communications devices (e.g., adynamic magnetic stripe communications device or RFID) and otherelectronics (e.g., buttons) that may allow a user to interact with thepowered card to perform one or more functions. Accordingly, for example,a powered card may be used to communicate specific information tocontactless communication device 162 by selective interaction with thebuttons of the powered card. In so doing, for example, a powered cardmay be used to interactively communicate magnetic stripe information(e.g., one, two, and/or three tracks of magnetic stripe data) tocontactless communication device 162 by sending a signal to a processorof a powered card (e.g., by pressing a button on the powered card) toinitiate such communications.

Contactless communication device 162 may receive variable data sets froma powered card based upon, for example, manual input provided to apowered card. For example, a button associated with an on-line purchasemay be pressed on the powered card that causes a variable data set(e.g., account number and expiration date) to be communicated from thepowered card to contactless communication device 162.

Discretionary data may, for example, be communicated by a powered cardbased upon which button was pressed on the powered card. In so doing,for example, a security code (e.g., “111”) may be communicated within adiscretionary data field when a button associated with a particularfeature (e.g., pay with credit) is pressed on the powered card. As peranother example, a different security code (e.g., “222”) may becommunicated within a discretionary data field when a button associatedwith a different feature (e.g., pay with debit) is pressed on thepowered card. Accordingly, for example, processor 158 may identify whattype of device may be in communication with contactless communicationdevice 162 by analyzing the data communicated to contactlesscommunication device 162.

Architecture 150 may include memory 160 and/or processor 158 may includeinternal memory. Accordingly, for example, application code may bestored within memory 160 and/or processor 158 and executed by processor158 in support of functions performed by architecture 150. For example,an application (e.g., a graphical user interface) may be executed byarchitecture 150 and displayed onto display 154, which may be used tointeract with a user of a mobile device (e.g., mobile device 100 of FIG.1). Persons skilled in the art will appreciate that executableapplication code may be communicated to architecture 150 via any one ormore interfaces of architecture 150 (e.g., user interface 152, display154, transceiver 156, and/or contactless communication device 162).

Application data (e.g., payment card data) may be stored within memory160 and accessed by processor 158 during operation. For example, paymentcard data may be stored within memory 160 and recalled by processor 158during a financial transaction being conducted by a mobile device (e.g.,mobile device 100 of FIG. 1). Once recalled, processor 158 maycommunicate the payment card data via transceiver 156 and/or contactlesscommunication device 162 to complete a financial transaction.

FIG. 2 shows network topology 200 that may include, for example, mobiledevice 202 (e.g., a mobile telephonic device, a PDA, an electronictablet, a laptop, a GPS unit, or an MP3 player). Mobile device 202 may,for example, include a contactless interface that may initiate, sustain,and/or terminate communication channel 226 between contactless device204 and mobile device 202. Contactless device 204 and mobile device 202may communicate via channel 226 using any number of contactless mediums,which may include for example, visible, audible, capacitive,electromagnetic, magnetic, and/or RF mediums.

Mobile device 202 may provide one or more transceivers that maycommunicate with one or more wired networks (e.g., IP network 212 and/orpayment network 214) and/or one or more wireless networks (e.g., mobilenetwork 210). Mobile device 202 may, for example, communicate with acellular station over a wireless radio interface (e.g., a GSM airinterface) that may be used by mobile device 202 to communicateinformation (e.g., voice and data) to cellular network accessinfrastructure 206 (e.g., one or more GSM base transceiver stations,base station controllers, and mobile switching centers). Persons skilledin the art will appreciate that cellular network access infrastructure206 may utilize any multiple access architecture, such as for example, acode-division multiple access architecture and/or a time-divisionmultiple access architecture.

Mobile device 202 may, for example, communicate with wireless accesspoint 208 over a wireless interface (e.g., a Bluetooth interface or aWi-Fi interface). Accordingly, for example, mobile device 202 may accessone or more wired networks (e.g., IP network 212 and/or payment network214) and/or one or more wireless networks (e.g., mobile network 210)without the need to first gain access to cellular network accessinfrastructure 206.

Contactless device 204 may, for example, be a powered card or anon-powered card (e.g., a powered payment card or a non-powered paymentcard). Accordingly, for example, payment information (e.g., a paymentaccount number and a card expiration date) may be communicated fromcontactless device 204 to mobile device 202 in support of a financialtransaction being conducted by mobile device 202. In so doing, forexample, items for purchase on IP network 212 (e.g., the internet) maybe accessed by a browser of mobile device 202 via an access point (e.g.,wireless access point 208 or cellular network access infrastructure206). Mobile device 202 may, for example, complete a purchasetransaction by first obtaining required payment information fromcontactless device 204 and then communicating such payment informationto network entities (e.g., payment server 216 and/or issuer 220).

Payment server 216 may, for example, contact issuer 220 via a network(e.g., payment network 214) with payment information received frommobile device 202 for authorization of a purchase. Once authorized,payment transaction information may be recorded onto a receipt that maybe delivered to mobile device 202 via any one or more delivery options(e.g., via a short messaging service of mobile network 210 or an emaildelivery service of IP network 212).

A payment receipt may, for example, be provided to mobile device 202 asa proof-of-purchase object (e.g., a barcode) that may be provided to adisplay of mobile device 202 and read by other computing equipment(e.g., a barcode scanner) for proof-of-purchase confirmation.

A mobile device (e.g., mobile device 224) may, for example, include acontactless communication device (e.g., an RFID) that may initiate,sustain, and/or terminate contactless communication channel 228 withmerchant terminal 218. Accordingly, for example, mobile device 224 maycommunicate payment information to merchant terminal 218 to complete afinancial transaction. In so doing, for example, mobile device 224 mayfirst receive payment information via contactless communication channel230 from contactless device 222 (e.g., a non-powered card), temporarilystore the received payment information within a memory of mobile device224, and forward the payment information onto merchant terminal 218 tocomplete a financial transaction. As per another example, mobile device224 may provide previously stored financial information associated withone or more payment cards (e.g., one or more non-powered payment cards).Accordingly, for example, payment information may be recalled from amemory of mobile device 224 and communicated to merchant terminal 218via contactless communication channel 228 to complete a financialtransaction using merchant terminal 218.

FIG. 3 shows system 300, which may include mobile device 302 and paymentcard 304. Mobile device 302 may, for example, be a laptop computer, aPDA, a mobile telephonic device (e.g., a smartphone), an MP3 player, aGPS, or any other mobile device. Display 308 may be a touch-sensitivedisplay (e.g., sensitive to a change in capacitance). Payment card 304may, for example, be a powered payment card or a non-powered paymentcard.

Mobile device 302 and payment card 304 may each include a contactlesscommunication device (e.g., RFID) that may communicate via a contactlesscommunication channel that may be formed between mobile device 302 andpayment card 304 after coming into proximity to one another. Paymentcard 304 may, for example, be tapped onto display 308 of mobile device302 to establish a proximity relationship that forms a communicationchannel between payment card 304 and mobile device 302. As per anotherexample, payment card 304 may be brought within a proximity distance(e.g., up to two inches) of mobile device 302 to establish a contactlesscommunication channel between mobile device 302 and payment card 304.

A processor of mobile device 302 may, for example, execute applicationcode that may generate a graphical user interface (GUI) onto display 308of mobile device 302. Message 306 of a GUI may invite a user of mobiledevice 302 to begin a mobile payment by tapping a payment card againstdisplay 308. As per another example, by tapping payment card 304 againstmobile device 302, mobile device 302 may autonomously determine that amobile payment is desired and then generate a mobile payment GUI ontodisplay 302.

Mobile device 302 may, for example, autonomously determine a type ofcard that may be tapped against it. For example, a processor of mobiledevice 302 may receive payment card data that may be indicative of anon-powered payment card (e.g., payment card data received from anon-powered card may not provide a security code associated with thecard). As per another example, a processor of mobile device 302 mayreceive data that may be indicative of a powered card (e.g., paymentcard data received may contain a dynamically generated security code).Payment card data received from a powered card may, for example, includea dynamic security code that may change depending upon a type oftransaction being conducted (e.g., debit or credit transaction).

As per another example, payment card 304 may be a powered payment cardthat may include electronics to simulate a human touch (e.g., paymentcard 304 may generate a change in capacitance that may be sensed bydisplay 308). Through a series of simulated touches, payment card 304may communicate a series of data bits to display 308, which may then beprocessed by a processor of mobile device 302. In so doing, for example,a contactless communication channel may be established where data istransferred from payment card 304 to mobile device 302 via a series ofsimulated touches.

Payment card 304 may, for example, include a light sensor. Accordingly,for example, payment card 304 may be sensitive to light pulses generatedwithin a region of display 308. The light sensor of payment card 304 mayreceive a series of light pulses, which may be construed by a processorof payment card 304 as data generated by mobile device 302. In so doing,for example, payment card 304 may receive an optical data streamrepresented by a series of light pulses generated by display 308. Assuch, a two-way communication channel may be formed, where simulatedtouches may generate a data stream from payment card 304 to mobiledevice 302 and light pulses may generate a data stream from mobiledevice 302 to payment card 304.

FIG. 4 shows GUI 400, that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 400 may,for example, generate results of a card detection operation that may beperformed by a processor of a mobile device. For example, cardinformation may be exchanged between a card and a mobile device via acontactless communication channel that may identify a type of card thatis being presented to the mobile device. Any type of card may bedetected by a processor of a mobile device, such as for example, anairline card, a travel card, a bank card, a healthcare card, anidentification card, and a loyalty rewards card. A card numbercommunicated to a mobile device may, for example, be indicative of acard type (e.g., bank card 404) that is presented to a mobile device.Accordingly, for example, a processor of a mobile device may identify acard type presented to the mobile device by analyzing a card numberreceived from the card and may indicate the identified card type via GUI400 (e.g., the identified card type may be generated onto GUI 400 havinga different graphical presentation than the other card types listed).

A GUI may, for example, provide navigation aids. A GUI may, for example,provide navigation aids that may be touch sensitive. For example, GUI400 may include navigation aids 406 and 408 to enable a user to revertto a previous GUI or advance to a subsequent GUI. Accordingly, forexample, a user may touch an area on a display of a mobile device thatdisplays a navigation aid to activate the touched navigation aid. In sodoing, for example, a user may touch navigation aid 406 to revert to theprevious GUI or a user may touch navigation aid 408 to advance to thenext GUI.

FIG. 5 shows GUI 500, that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 500 may,for example, generate results of a payment card detection operation thatmay be performed by a processor of a mobile device. A non-poweredpayment card may, for example, communicate a single payment card numberthat may be associated with a number of payment options (e.g., debit,credit, or points). Accordingly, for example, GUI 500 may be generatedto allow a user an opportunity to select which payment option (e.g.,credit option 502) from a number of payment options is to be used tosettle a payment transaction. Once identified, a payment optionselection (e.g., credit option 502) may be communicated by a mobiledevice to an issuer of the payment card to settle the transaction usingthe selected payment option.

As per another example, a powered payment card may include a userinterface to allow a user to select from a number of payment options. Abutton on a powered payment card may, for example, be associated withone payment method (e.g., pay with credit) and another button may, forexample, be associated with another payment method (e.g., pay withpoints). Data associated with the selected payment method may becommunicated from a powered payment card to a mobile device.Accordingly, for example, a processor of a mobile device may detect thepayment method communicated by a powered payment card (e.g., ascommunicated within a discretionary data field) and may autonomouslygenerate a graphical representation of the payment method selected(e.g., GUI 500 may autonomously generate a graphical representation thatcredit method 502 was selected).

FIG. 6 shows GUI 600 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 600 may,for example, include a bank card validation screen as may be generatedby a processor of a mobile device. A mobile device may, for example,challenge a user of the mobile device to enter a PIN that may beassociated with a payment card (e.g., VISA credit 602) that waspreviously presented to the mobile device for payment. GUI 600 may, forexample, generate virtual pin pad 606 that may include touch-sensitivebuttons having alphanumeric indicia associated with each button. A usermay touch one or more buttons of pin pad 606 that may correspond torespective characters of a PIN and an indication of the user's selectionmay appear within area 604. Characters displayed within area 604 may,for example, be hidden for security purposes.

Activation of virtual button 608 may, for example, cause a processor ofa mobile device to compare a PIN entered by a user of the mobile deviceto a PIN that may be associated with the payment card presented to themobile device for payment. The PIN may, for example, be stored withinprotected memory of the mobile device, so that a processor of the mobiledevice may locally determine the validity of the PIN entered.Alternately, for example, the mobile device may communicate the PIN tothe issuing bank for a remote validation of the PIN entered. Personsskilled in the art will appreciate that a user interface (e.g., a keypador keyboard) of a mobile device may be used instead of virtual pin pad606 to enter the one or more characters of a PIN.

FIG. 7 shows GUI 700 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 700 may,for example, include a bank card validation screen as may be generatedby a processor of a mobile device. A mobile device may, for example,challenge a user of the mobile device to enter a security code that maybe associated with a payment card (e.g., VISA credit 702) that waspreviously presented to the mobile device for payment. Such a securitycode (e.g., a CVV code) may, for example, be printed on the back of thepayment card.

GUI 700 may, for example, generate virtual pin pad 706 that may includetouch-sensitive buttons having alphanumeric indicia associated with eachbutton. A user may touch one or more buttons of pin pad 706 that maycorrespond to respective characters of a security code and an indicationof the user's selection may appear within area 704. Characters displayedwithin area 704 may, for example, be hidden for security purposes.

Activation of virtual button 708 may, for example, cause a processor ofa mobile device to compare a security code entered by a user of themobile device to a security code that may be associated with the paymentcard presented to the mobile device for payment. The security code may,for example, be stored within protected memory of the mobile device, sothat a processor of the mobile device may locally determine the validityof the security code entered. Alternately, for example, the mobiledevice may communicate the security code to the issuing bank for aremote validation of the security code entered. Persons skilled in theart will appreciate that a user interface (e.g., a keypad or keyboard)of a mobile device may be used instead of virtual pin pad 706 to enterthe one or more characters of a security code.

FIG. 8 shows GUI 800 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 800 may,for example, include a bank card validation screen as may be generatedby a processor of a mobile device. A mobile device may, for example,maintain memory of one or more payment cards previously presented to themobile device for payment. A mobile device may, for example, allow auser to store payment information within the mobile device that may beassociated with a payment card to be used at some point in the future.

Accordingly, for example, a user may recall payment informationpreviously stored in memory of a mobile device in order to complete apurchase transaction using the mobile device. In order to validate thata user of a mobile device is actually the owner of payment informationrecalled from memory of the mobile device, GUI 800 may challenge theuser to present the physical payment card whose associated paymentinformation was recalled from memory. In so doing, for example, GUI 800may prevent a fraudulent user of a mobile device from authorizing apurchase using payment information stored in memory of the mobile devicethat is not owned by the fraudulent user.

A user may, for example, be required to present a physical payment cardto GUI 800 by placing (or tapping) the physical payment card within aproximity of a display of a mobile device that is generating GUI 800. Inso doing, for example, a contactless communication channel (e.g., anRFID communication channel) may be established between the physicalpayment card and the mobile device, such that payment information may becommunicated from the physical payment card to the mobile device. Uponverification that the communicated payment information matches paymentinformation stored in memory of the mobile device, the paymentinformation may be validated and authorized to be communicated from themobile device to a network entity (e.g., a payment server or the issuerof the payment card) for settlement of the purchase transaction.

FIG. 9 shows GUI 900 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 900 may,for example, include validation area 902 as generated by a processor ofa mobile device. Validation area 902 may, for example, include one ormore data exchange areas (e.g., data exchange areas 904 and 906). Icon904 may, for example, be generated by GUI 900 within an area of adisplay of a mobile device that may be sensitive to touch (e.g., an areathat may be sensitive to a capacitance change). Area 906 may, forexample, be generated by GUI 900 within an area of a display of a mobiledevice that may generate pulses of light.

A powered payment card may be validated for use by a mobile devicethrough an exchange data with the powered payment card via data exchangeareas 904 and 906. For example, a powered payment card may be pressedagainst validation area 902 so that a touch simulation device of thepowered payment card aligns with data exchange area 904 and a lightsensing device aligns with data exchange area 906. Accordingly, forexample, the powered payment card may communicate information to aprocessor of a mobile device by simulating a series of touches in dataexchange area 904 and data may be communicated to the powered paymentcard by a processor of the mobile device by generating a series of lightpulses in data exchange area 906. In so doing, for example, a mobiledevice and a powered payment card may exchange validation information sothat payment card information stored within the mobile device may bevalidated for use.

A mobile device may, for example, include a motion capture device (e.g.,a camera) and a powered payment card may, for example, include a lightsource (e.g., an LED). Accordingly, for example, information (e.g.,validation information) may be exchanged between a mobile device and apowered payment card such that information communicated by the poweredpayment card may be communicated as a series of light pulses while thecamera of the mobile device captures the series of light pulses. Aprocessor of the mobile device may construe the series of light pulsesas information that may be used, for example, as validation information.

FIG. 10 shows GUI 1000 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1000 may begenerated, for example, after payment card information has beencommunicated by either of a non-powered payment card or a poweredpayment card to a mobile device. A user of a mobile device may, forexample, elect whether to store such payment card information within amemory location of the mobile device. If a user chooses not to storepayment information received from a payment card (e.g., as elected byselection of radio button 1004), a mobile device may delete all paymentinformation previously received from a payment card after the paymentinformation is used to complete a purchase transaction. Accordingly, auser wishing to use the same payment card to complete a paymenttransaction in the future is required to present the payment card to themobile device so that the payment card may communicate payment cardinformation to the mobile device in order to complete the paymenttransaction. If a user chooses to store payment information receivedfrom a payment card (e.g., as elected by selection of radio button1002), a mobile device may store a portion of, or all, paymentinformation previously received from a payment card in accordance with auser's preference.

FIG. 11 shows GUI 1100 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1100 may,for example, offer storage options to a user of a mobile device that haselected to store a portion of, or all, payment card informationpreviously communicated to the mobile device by a non-powered card or apowered card. A data storage option may, for example, be selected by auser of a mobile device (e.g., by touching a portion of text box 1102)that stores only a portion (e.g., an expiration date and payment cardaccount number) of the payment card information into a memory of themobile device. Accordingly, for example, a payment card may communicateone, two, and/or three tracks of magnetic stripe data to a mobiledevice, but the only payment information stored within a memory of themobile device upon selection of text box 1102 is the expiration date andthe payment card account number. All remaining information that may havebeen communicated by the payment card to the mobile device may bedeleted by the mobile device.

Selection of text box 1104 may, for example, cause all paymentinformation communicated by a payment card to a mobile device to bestored within a memory of the mobile device. Accordingly, for example, amobile device may use a portion or all of the payment information storedwithin its memory to complete a purchase transaction. However, paymentcard validation information (e.g., a PIN or security code) may still berequired to be entered by a user of the mobile device before the mobiledevice may complete a purchase transaction with the stored paymentinformation.

Selection of box 1106 may, for example, cause all payment informationcommunicated by a payment card to a mobile device to be stored within amemory of the mobile device. All validation information (e.g., a PIN orsecurity code) that may be entered by a user of the mobile device tovalidate payment information received from a payment card may also bestored within a memory of the mobile device. Accordingly, for example, amobile device may use a portion or all of the payment information,including validation information, stored within its memory to complete apurchase transaction.

Selection of box 1108 may, for example, cause all payment information,including discretionary data fields, communicated by a payment card to amobile device to be stored within a memory of the mobile device. Apowered payment card may, for example, allow a user of the poweredpayment card to select one or more options that may be associated withthe powered payment card. A powered payment card may, for example,communicate indicia associated with the one or more selected optionswithin discretionary data fields of magnetic stripe data that may becommunicated to a mobile device.

For example, a user of a powered payment card may elect to pay for apurchase using rewards points by pressing a button on the poweredpayment card that is associated with a rewards points payment option.Accordingly, for example, a powered payment card may insert a rewardspoints payment code within a discretionary data field of a first, asecond and/or a third track of magnetic stripe data and may communicateall track data, including the discretionary data field, to a mobiledevice. In so doing, for example, a processor of a mobile device maydetect such a payment code within a discretionary data field and maystore payment information within a memory of the mobile device that isindicative of the rewards points payment code contained within thediscretionary data field.

FIG. 12 shows GUI 1200 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1200 may,for example, offer a split-payment option to a user of a mobile device,such that the user may elect to split payment for a selected purchasebetween two or more payment accounts. The mobile device may, forexample, communicate payment information for each of the selectedsplit-payment accounts to respective network entities (e.g., issuer andpayment servers) of the selected split-payment accounts in order tosettle the amounts owing on each of the selected split-payment accounts.

A user may, for example, select option 1202 (e.g., by tapping a paymentcard against a display of a mobile device or by presenting a paymentcard within proximity to the mobile device). In so doing, for example, acontactless communication channel (e.g., an RFID communication channel)may be established between the payment card and the mobile device sothat payment information associated with the payment card may becommunicated by the payment card to the mobile device and used as asplit-payment account for a selected purchase.

An alternate contactless communication channel may be established, forexample, by pressing a payment card against portion 1208. Accordingly,for example, a payment card may communicate payment informationassociated with the payment card to a processor of a mobile device bysimulating a series of touches at a location within portion 1208 (e.g.,at icon 1210) and the processor of the mobile device may communicateinformation to the payment card by generating a series of light pulsesat a location within portion 1208 (e.g., at location 1212). In so doing,for example, payment information associated with the payment card may bereceived by a processor of a mobile device and used as a split-paymentaccount to partially cover the purchase price of a selected purchase.

Other contactless communication channels may be established. Forexample, a processor of a payment card may communicate paymentinformation to a mobile device by generating a series of light pulses(e.g., via an LED of the payment card), which may be captured by acamera of the mobile device and construed by a processor of the mobiledevice as payment information. As per another example, a payment cardmay communicate payment information using audible sounds that may bereceived by a microphone of a mobile device and construed by a processorof the mobile device as payment information.

A payment account may, for example, be selected from a memory of themobile device (e.g., by selecting radio button 1204). Associated paymentinformation may, for example, be selectively retrieved from a memory ofthe mobile device and used by the mobile device as a split-paymentaccount in partial payment for a selected purchase. Alternately, forexample, a split-payment option may be declined by a user of a mobiledevice (e.g., by selecting radio button 1206).

FIG. 13 shows GUI 1300 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1300 may,for example, provide a summary of split-payment methods that may havebeen selected by a user of a mobile device. Portion 1302, for example,may display an amount owing for a particular selected purchase. Portions1304-1308 may, for example, include an alphanumeric entry box to allow auser of a mobile device to input payment amounts (e.g., currency orpoints) that he or she wishes to apply towards a total amount owing asmay be displayed in portion 1302. Portions 1304-1308 may, for example,include those payment accounts that a user of a mobile device previouslyselected as split-payment accounts.

Accordingly, for example, a user may elect to charge $10 against a VISAcredit account, $35 against a M/C debit account, and 500 rewards pointsearned by the VISA credit account towards full payment of a $50 amountowing for a particular selected purchase. In so doing, for example, amobile device may communicate with selected network entities (e.g.,issuer and payment servers) to provide transaction informationassociated with each split-payment account selected, so that each amountowing may be settled.

Portions 1310-1314 may, for example, include alphanumeric entry boxes toallow a user of a mobile device to make comments on each accountselected as a split-payment account. Accordingly, for example, a mobiledevice may communicate notes that may be entered by a user withinportions 1310-1314 to, for example, a payment server. In so doing, forexample, receipts and/or account statements that may be generated by anetwork entity (e.g., an issuer or a payment server) may include suchnotes so that a user of a mobile device, upon receipt of such receiptsand/or account statements, may be reminded of his or her thought processwhen such a split-payment was transacted.

FIG. 14 shows GUI 1400 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1400 may,for example, offer checkout options to a user of a mobile device toallow a level of integration between the user and one or more issuers ofassociated payment accounts used by the mobile device in settlement of aselected purchase.

For example, a user may utilize billing tag list 1402 to categorize aselected purchase into one of many purchase categories. A user'sphysical presence may, for example, be at a fast-food establishmentwhere the user may select a food purchase from the fast-foodestablishment's website using a browser of the user's mobile device.Payment information used to settle a transaction associated with theselected food purchase may be collected and/or generated by the mobiledevice and forwarded onto a payment server and/or an associated issuerfor settlement. In addition, the mobile device may forward a billing tagselected from billing tag list 1402 to the associated issuer, so thatthe associated issuer may label the selected transaction on a billingstatement using the selected billing tag. In so doing, for example, auser may customize an accounting of the issuer's billing statement byusing a mobile device to communicate payment information and billingtags associated with selected purchases to track expenditures within thevarious purchase categories of billing tag list 1402.

A user of a mobile device may select receipt delivery options for eachpurchase that may be transacted using a mobile device. For example, areceipt delivery list may be generated by a processor of a mobile deviceso that a user of the mobile device may select a receipt deliveryoption. Accordingly, for example, the selected receipt delivery optionalong with payment information may be communicated by a mobile device toa payment server and the payment server (or other entity) may direct adelivery of the receipt based upon the receipt delivery option received.

A user may, for example, request delivery of a purchase receipt via textmessaging (e.g., by selecting receipt delivery option 1406). In sodoing, for example, a mobile device may complete a purchase transactionwith an entity of a payment network (e.g., a payment server) and mayfurther request that the payment server deliver a receipt to the mobiledevice in a text message format. Accordingly, for example, in additionto providing payment information to the payment server, a mobile devicemay also provide a text message address (e.g., an SMS text messageaddress) to the payment server. In so doing, for example, the mobiledevice may receive a receipt of the completed purchase transaction fromthe payment server via a text message at the text message addressprovided by the mobile device.

As per another example, a multimedia message (e.g., an MMS messagecontaining rich content) may be received by a mobile device from apayment server in the form of, for example, a graphical image (e.g.,barcode), such that the barcode may be used as a proof-of-purchase(e.g., proof-of-purchase of an airline ticket and an associated barcodethat gains access by the user of the mobile device to a particularseating assignment on the airplane.)

A receipt (e.g., a receipt received via multimedia messaging) may, forexample, provide rewards to a user of the mobile device for completingpayment transactions via a mobile device. For example, a mobile devicemay communicate indicia to a payment server that identifies a paymenttransaction as a mobile payment transaction. The communicated mobilepayment indicia may, for example, trigger a payment server to not onlyprovide a receipt for the purchase transaction to the mobile device, butalso to provide a multimedia game that may be executed by the mobiledevice. As per an example, an animated trivia question may becommunicated to a mobile device via an MMS message upon completion of amobile payment transaction. Upon successfully answering the animatedtrivia question, a user of the mobile device may receive another MMSmessage that contains a coupon for free merchandise from the merchantwhose goods were just purchased. As per another example, a receiptreceived from a payment server may itself contain coupons for discountedor free merchandise without requiring that a user of the mobile deviceperform any further actions beyond completing a mobile payment purchasewith a mobile device.

A user may, for example, request delivery of a purchase receipt viaemail (e.g., by selecting receipt delivery option 1408). In so doing,for example, an email address associated with the user may be providedby the mobile device to a payment server in addition to any requiredpayment information that may be required to complete a purchasetransaction. Accordingly, for example, a payment server may address areceipt to an email address received from a mobile device during amobile payment transaction.

A user may, for example, request delivery of a purchase receipt (e.g.,by selecting receipt delivery option 1410) via a format that may becompatible with an accounting software package (e.g., QuickBooks). Forexample, a mobile device may allow a user to categorize a particularpurchase within a particular expense account (e.g., an office supplyexpense account) during a purchase transaction. Once the purchasetransaction is completed, an electronic receipt may be communicated tothe mobile device that may be tagged with the categorized expenseaccount (e.g., the accounting software package may have its own addressthat receipts may be delivered to). In so doing, for example, anaccounting software package that may be executing on the mobile devicemay autonomously access the electronic receipt from its own address andmay autonomously enter the expense in the correct category so that allpurchases made by the mobile device may be correctly accounted forwithin the accounting software package.

A user may, for example, request delivery of a purchase receipt (e.g.,by selecting receipt delivery option 1412) via a format that may becompatible with the bank that issued the selected payment account.Accordingly, for example, a payment server may forward a receipt of thepurchase transaction to the issuing bank and the issuing bank may formatthe receipt for delivery with the user's month-end account statement.

A user may, for example, enter comments about a purchase transactionthat may be included within a receipt. For example, a user may entercomments 1404 that may remind the user to include the receipt within hisor her tax records because the purchase may be deemed as tax deductible.Accordingly, for example, comments 1404 may accompany paymentinformation communicated by a mobile device to a payment server. In sodoing, for example, a payment server may add comments 1404 to a receiptgenerated by the payment server and may forward the receipt with theadded comments to the user of the mobile device as dictated by thereceipt delivery options requested by the user of the mobile device.

FIG. 15 shows GUI 1500 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1500 may,for example, offer a check-out option to a user of a mobile device, suchthat the user may elect to apply a rewards card to a selected purchasein order for the rewards card to accrue points for the purchase. Themobile device may, for example, submit rewards card information andtransaction information to respective issuers of the rewards account sothat the respective issuers may credit the rewards account accordingly.

A user may, for example, select option 1502 (e.g., by tapping a rewardscard against a display of a mobile device or by presenting a rewardscard within proximity to the mobile device). In so doing, for example, acontactless communication channel (e.g., an RFID communication channel)may be established between the rewards card and the mobile device sothat information associated with the rewards card may be communicated bythe rewards card to the mobile device.

An alternate contactless communication channel may be established, forexample, by pressing a rewards card against portion 1508. Accordingly,for example, a rewards card may communicate information associated withthe rewards card to a processor of a mobile device by simulating aseries of touches within portion 1508 (e.g., at icon 1510) and theprocessor of the mobile device may communicate information to therewards card by generating a series of light pulses within portion 1508(e.g., at location 1512). In so doing, for example, rewards informationassociated with the rewards card may be received by a mobile device andcommunicated to an issuer of the rewards card so that the rewardsaccount may be updated with the purchase transaction information.

Other contactless communication channels may be established. Forexample, a processor of a rewards card may communicate rewardsinformation to a mobile device by generating a series of light pulses(e.g., via an LED of the rewards card), which may be captured by acamera of the mobile device and construed by a processor of the mobiledevice as rewards information. As per another example, a payment cardmay communicate payment information using audible sounds that may bereceived by a microphone of a mobile device and construed by a processorof the mobile device as payment information.

A rewards account may, for example, be selected from a memory of themobile device (e.g., by selecting radio button 1504). Associated rewardsinformation may, for example, be selectively retrieved from a memory ofthe mobile device and communicated by the mobile device to an issuer ofthe rewards account so that the rewards account may be credited with theselected purchase.

A user of a mobile device may, for example, place an order for a rewardscard by selecting radio button 1506. Accordingly, for example, a mobiledevice may communicate payment information to a payment server tocomplete a purchase transaction and may also communicate a request thata rewards account be created. A payment server may, for example, forwardthe rewards account creation request to an issuer of a rewards accountalong with details of the purchase transaction, so that the issuer mayfirst create the rewards account and may then credit the accountaccording to the purchase transaction. Accordingly, for example, anelectronic version of a newly created rewards card (e.g., a graphicalrepresentation of a newly created rewards card) may, for example, becommunicated to a mobile device which may, for example, include abarcode representation of the rewards account information. In addition,rewards card information may, for example, be added to a memory of amobile device for future access.

FIG. 16 shows GUI 1600 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1600 may,for example, challenge a user of a mobile device to enter an access codethat may be required to authenticate a purchase transaction. GUI 1600may, for example, include virtual keyboard 1604 to allow a user of amobile device to enter such an access code. Alternately, for example, amanual input interface of a mobile device (e.g., a keyboard or a keypad)may be used to enter such an access code.

As a user of a mobile device enters each character of an access code,portion 1602 may reflect such entry. Such entries may, for example, bereflected within portion 1602 as protected characters (e.g., the actualvalue of each character may be blocked out) to protect the security andsafety of the entered access code. Once an entered access code isverified and authenticated by a mobile device, the mobile device maycomplete the requested purchase transaction.

FIG. 17 shows GUI 1700 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1700 may,for example, include portion 1702 that may display a graphicalrepresentation of a proof-of-purchase (e.g., a barcode). Such aproof-of-purchase may be communicated to a mobile device via a networkentity (e.g., a payment server) upon completion of a purchasetransaction by the mobile device.

Accordingly, for example, portion 1702 may graphically display aproof-of-purchase that may be recognized by a reader (e.g., a barcodereader). In so doing, for example, a system that may include a barcodereader may verify the validity of a proof-of-purchase barcode, which maythen allow a user of a mobile device displaying such a barcode to enjoythe goods and/or services purchased by the user via the mobile device asacknowledged by the verified barcode. As per one example, such averified barcode may allow entry onto an airplane having a seatassignment that is encoded within the barcode. As per another example, auser may have made an on-line purchase of an appliance using his or hermobile device and may have requested pick-up of the purchased applianceat an appliance inventory warehouse. Upon arrival at the applianceinventory warehouse, a user may retrieve an electronic proof-of-purchase(e.g., a barcode) from a memory of the mobile device that was receivedby the user's mobile device upon completion of the appliance purchasetransaction. A reader (e.g., a barcode reader) at the applianceinventory warehouse may read the user's barcode directly from a displayof the user's mobile device, verify that a purchase was completed by theuser's mobile device, and may authorize the appliance for pickup by theuser.

FIG. 18 shows GUI 1800 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1800 may,for example, enable a funds transfer to one or more financial accounts.GUI 1800 may, for example, enable a transfer of funds (e.g., byselecting radio button 1802) directly from one or more financialaccounts into one or more financial accounts. GUI 1800 may, for example,generate a communication channel with a recipient of a funds transfer(e.g., by selecting radio button 1804) and may allow the recipient tointeractively determine the financial account that is to receive thetransferred funds.

FIG. 19 shows GUI 1900 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 1900 may,for example, enable a funds transfer to one or more accounts. GUI 1900may, for example, allow a user of a mobile device to select an object(e.g., by selecting an entry within menu list 1902) that may beassociated with the funds transfer. GUI 1900 may, for example, allow auser to select an account (e.g., by selecting an entry within menu list1904) that may be associated with the object selected within menu list1902.

Accordingly, for example, a mobile device may include a memory withinwhich a user may enter one or more potential recipients of a fundstransfer. A processor of a mobile device may, for example, list eachpotential recipient of a funds transfer within menu list 1902. A user ofa mobile device may, for example, select a recipient of a funds transferby activating (e.g., touching) an entry within menu list 1902 thatcorresponds to the selected recipient. As per an example, a user's fundstransfer recipient list, as may be reflected by menu list 1902, mayinclude persons, financial accounts, inanimate objects, or any othertype of object.

Once a selected funds transfer recipient is selected within menu list1902, menu list 1904 may be populated. Accordingly, for example, amobile device may include a memory within which a user may enter one ormore accounts that may be associated with one or more potentialrecipients of a funds transfer. A processor of a mobile device may, forexample, list each account in menu list 1904 that may be associated withthe selected recipient of menu list 1902. A user of a mobile device may,for example, select an account for a funds transfer by activating (e.g.,touching) an entry within menu list 1904 that corresponds to theselected account. As per an example, a user's funds transfer accountlist, as may be reflected by menu list 1904, may include any accountthat may be associated with the selected recipient of menu list 1902.

FIG. 20 shows GUI 2000 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 2000 may,for example, enable a funds transfer from a source account (e.g., anaccount associated with a payment card that is tapped against a displayof a mobile device) to a target account (e.g., a car loan account).Portion 2002 may, for example, list account details that may beassociated with a target account (e.g., an account number associatedwith a car loan, the payoff amount, and the amount due). Portion 2002may, for example, include details that may be associated with a targetaccount that a mobile device has collected from a network entity (e.g.,a bank) via a network connection between the mobile device and thenetwork entity.

Portion 2004 (e.g., an alphanumeric entry box) may, for example, allow auser of a mobile device to enter an amount to be transferred (e.g., anamount that is equal to the minimum amount due on an installment paymentagreement). GUI 2000 may, for example, request an identification of asource account from which the amount will be transferred. As per anexample, a user of a mobile device may tap a payment card against adisplay of the mobile device to establish a contactless communicationchannel between the payment card and the mobile device within whichpayment information may be communicated from the payment card to themobile device. As per another example, a payment card may communicatepayment information to a mobile device via a series of touch simulations(e.g., changes in capacitance generated by a payment card that may bedetected by a touch-sensitive display of a mobile device). A series oflight pulses, or audible information, for example, may be communicatedby the payment card to the mobile device in order to communicate paymentinformation.

GUI 2000 may, for example, display a summary of payment information thatmay have been received by a mobile device from a payment card via acontactless communication channel. For example, portion 2006 may bedisplayed by GUI 2000 to allow a user of a mobile device to confirm theidentity of a payment account from which an amount of money will betransferred. Once confirmed, the mobile device may communicate withnetwork entities (e.g., an issuer of the source account and a bankassociated with the target account) to complete the money transfer.

FIG. 21 shows GUI 2100 that may be generated by a processor of a mobiledevice and provided onto a display of the mobile device. GUI 2100 may,for example, enable a funds transfer to an account associated with aperson. A recipient may, for example, interactively select an accountinto which the funds will be transferred. Accordingly, for example,contact list 2102 may be displayed by GUI 2100 as a list of potentialrecipients of a money transfer. Contact method list 2104 may, forexample, by displayed by GUI 2100 as a list of methods that may be usedto contact the recipient as selected within contact list 2102. In sodoing, for example, a person within contact list 2102 (e.g., Trace) maybe selected by a user of a mobile device to be the recipient of a fundstransfer and the recipient may be contacted, for example, in accordancewith a method selected in contact method list 2104 (e.g., transferalert).

FIG. 22 shows system 2200, which may include mobile device 2202,receiving device 2204, and network 2210. Mobile device 2202 may be adevice used to coordinate a money transfer and receiving device 2204 maybe a device used to coordinate receipt of a money transfer. Receivingdevice may, for example, be a mobile device. Receiving device, forexample, may not be a mobile device (e.g., a desktop computer). Devices2202-2204 may communicate via network 2210, which may include anycombination of cellular network resources, wireless network resources,and/or wired network resources.

Mobile device 2202 may, for example, include a processor that may rendermoney transfer GUI 2206 onto a display of mobile device 2202. GUI 2206may, for example, pause while a user of mobile device 2202 selects apayment account from which a money transfer may be withdrawn.Accordingly, for example, mobile device 2202 may wait until a paymentcard is brought within a proximity to, or a touch relationship with,mobile device 2202 (e.g., a payment card may be tapped onto a display ofmobile device 2202). Alternately, for example, a payment card maycommunicate with mobile device 2202 using any number of contactlessmethods (e.g., using light, sound, capacitive, magnetic orelectromagnetic communication). In so doing, for example, mobile device2202 may establish a contactless communication channel with a paymentcard in which payment information is communicated from the payment cardto mobile device 2202 and is summarized onto GUI 2206 for review by auser of mobile device 2202. A user of mobile device 2202 may enter anamount of money for transfer, may verify a money amount for transfer,and may enter a message to be communicated to receiving device 2204.

Mobile device 2202 may communicate payment information received from apayment card along with information received from a user of mobiledevice 2202 to a network entity (e.g., an issuer) where, for example,authorization of the transfer amount from the account selected isperformed. Once authorized, mobile device 2202 may communicate atransfer alert along with a transfer alert message to receiving device2204. Receiving device 2204 may, for example, present a transfer alertalong with the associated transfer alert message onto GUI 2208. A userof receiving device 2204 may respond to the transfer alert messagereceived from mobile device 2202 by sending an acknowledgment message tomobile device 2202 via network 2210.

A user of receiving device 2204 may, for example, be asked to enteraccount information that is to be used as the receiving account for themoney transfer. Accordingly, for example, a user of receiving device2204 may provide such account information any number of ways. Forexample, a payment card associated with a receiving account may bebrought within a proximity, or a touching, relationship to receivingdevice 2204. In so doing, for example, a contactless communicationchannel (e.g., an RFID channel) may be formed to communicate suchinformation. Alternately, a payment card may communicate with receivingdevice 2204 using any number of contactless methods (e.g., using light,sound, capacitive, magnetic or electromagnetic communication). A user ofreceiving device 2204 may verify the receive account information as itmay be displayed onto GUI 2208.

Receiving device 2204 may, for example, communicate informationassociated with a receiving account to mobile device 2202 via network2210. Accordingly, for example, mobile device 2202 may coordinate themoney transfer via network 2210 with network entities (e.g., an issuerof the account used to provide money to transfer and an issuer of theaccount used to receive money for transfer). Once the money transfer iscompleted, an acknowledgment message may be displayed onto GUI 2206 by aprocessor of mobile device 2202 and an acknowledgment message may becommunicated by mobile device 2202 to receiving device 2204 and thendisplayed onto GUI 2208 by a processor of receiving device 2204.

FIG. 23 shows system 2300, which may include a mobile device 2302, apowered or non-powered payment card 2304, a remote application 2308 andnetwork 2306. Mobile device 2302 may, for example, access remoteapplication 2308 via network 2306 in order to complete a purchasetransaction. Accordingly, for example, payment card 2304 may communicatepayment information to mobile device 2302 via contactless communicationchannel 2312 and mobile device 2302 may communicate the paymentinformation to remote application 2308 via communication channel 2310 tocomplete the purchase transaction.

Contactless communication channel 2312 may be any type of contactlesscommunication channel, such as for example, an RF, capacitive, audible,visible, electromagnetic, or magnetic communication channel. Contactlesscommunication channel 2312 may be a two-way communication channel, wheremobile device 2302 may communicate with payment card 2304 in order to,for example, enhance data communication between mobile device 2302 andpayment card 2304.

As per one example, payment card 2304 may communicate paymentinformation (e.g., one, two, and/or three tracks of magnetic stripedata) to mobile device 2302 after payment card 2304 is tapped againstmobile device 2302. Remote application 2308 may, for example, be anon-line payment application that does not require a fully populatedmagnetic stripe message to complete a purchase transaction, but may onlyrequire a subset of a fully populated magnetic stripe message (e.g.,account number and expiration date). Accordingly, for example, mobiledevice 2302 may filter payment information received from payment card2304 to only include the subset of information that may be required byremote application 2308 and may communicate only the filtered paymentinformation to remote application 2308 to complete the purchasetransaction.

In general, for example, mobile device 2302 may filter paymentinformation received from payment card 2304 into a filtered subset ofpayment data that may be required by remote application 2308 to completea purchase transaction. In so doing, for example, mobile device 2302 maycustomize a payment message to remote application 2308 that includesonly the filtered subset of data that is needed by remote application2308 to complete the purchase transaction.

As per another example, mobile device 2302 may query payment card 2304via contactless communication channel 2312 for only a subset of paymentinformation that may be required by remote application 2308 to completea purchase transaction. Accordingly, for example, a processor of paymentcard 2304 may receive the request and may only supply the requestedpayment information via contactless communication channel 2312 insteadof communicating a complete magnetic stripe message.

FIG. 24 shows system 2400, which may include a mobile device 2402, apayment card 2404, a rewards card 2416, and items to be purchased2410-2414. Mobile device 2402 may, for example, include a scanningdevice (e.g., a camera) that may be used to capture images (e.g.,barcode images). Accordingly, for example, a user of mobile device 2402may activate an application within mobile device 2402 that generates GUI2408 and that activates a camera to capture barcode images. A processorof mobile device 2402 may, for example, analyze captured barcode imagesto extract information from the barcode images and construe theextracted information as data input. Accordingly, for example, a cameraof mobile device 2402 may be used to scan barcodes of items that theuser wishes to purchase and a processor of mobile device 2402 mayanalyze the scanned information to keep a running total of itemsselected for purchase. In so doing, for example, a user of mobile device2402 may wander through a shopping market while scanning barcode labelsof items for purchase (e.g., items 2410-2414).

Mobile device 2402 may access a network (e.g., a local Wi-Fi hotspot)within a shopping market to determine those items that may be offered ata discount to rewards members of the shopping market. Accordingly, forexample, a user may scan barcode image 2418 of rewards card 2416 toobtain an instant credit for discounted items for purchase. As peranother example, rewards card 2416 may establish a contactlesscommunication channel with mobile device 2402 so that rewards card 2416may communicate rewards account information to mobile device 2402 viaany one of a number of contactless communication mediums (e.g., RF,capacitive, audible, visible, electromagnetic, or magnetic communicationmediums).

Once a user of mobile device 2402 finishes shopping, the user maypresent payment card 2404 to mobile device 2402 for payment.Accordingly, for example, contactless communication channel 2406 (e.g.,an RF, capacitive, audible, visible, electromagnetic, or magneticcommunication channel) may be created and payment information may becommunicated from payment card 2404 to mobile device 2402 so that mobiledevice 2402 may complete the purchase transaction with a network entity(e.g., an issuer of payment card 2404).

FIG. 25 shows system 2500, which may include mobile device 2502 andpayment card 2504. Mobile device 2502 may interact with a merchantestablishment (e.g., a restaurant) to gain entry into a user's tab atthe merchant's establishment (e.g., a food and alcohol bill generated bythe restaurant). Accordingly, for example, a user may monitor each itemon the bill, enter an additional amount into the bill (e.g., a tip), andthen pay the bill all from the convenience of the user's mobile device2502.

Interaction with a merchant establishment may be accomplished any numberof ways. For example, mobile device 2502 may access a local Wi-Fihotspot and may communicate information (e.g., an email address or textmessaging address) to the merchant that identifies a user of mobiledevice 2502. Accordingly, for example, a merchant may send a message(e.g., an email or text message) to the user-supplied address that maycontain a link to the user's bill. A user may, for example, click on thelink, enter a pass code to gain entry to the user's bill, and thenmonitor the bill being generated onto a display of mobile device 2502via GUI 2508.

As per another example, mobile device 2502 may place a phone call to amerchant's phone number to establish a communication channel (e.g., adata call) between the merchant server and mobile device 2502. Themerchant server may, for example, render GUI 2508 onto a display ofmobile device 2502 so that a user of mobile device 2502 may directlyinteract with the merchant server.

GUI 2508 may be rendered onto a display of mobile device 2502 to allow auser to remotely interact with his or her bill. For example, a user'smeal tab at a restaurant may be itemized by GUI 2508 and an alphanumericentry box (e.g., box 2510) may allow the user to enter additional data(e.g., add a tip to the bill). A user may, for example, review a totalto be charged, verify such a total, and then present payment card 2504to mobile device 2502 to settle the total amount. In so doing, forexample, contactless communication channel 2506 may receive paymentinformation from payment card 2504 via any number of contactlesscommunication mediums (e.g., RF, capacitive, audible, visible,electromagnetic, or magnetic communication mediums) and may communicatesuch payment information to a network entity (e.g., an issuer of paymentcard 2504) to complete a purchase transaction for the total amount ofthe user's bill.

FIG. 26 shows flow charts for process sequences 2610-2650. Processsequence 2610 may, for example, execute a payment application on amobile device (e.g., as in step 2611) to request a user of the mobiledevice to present a payment card to the mobile device. In step 2612, auser may present a payment card (e.g., tap a payment card onto a displayof a mobile device) to begin a payment transaction. In step 2613, acontactless communication channel (e.g., an RF, capacitive, audible,visible, electromagnetic, or magnetic communication channel) may begenerated between a payment card and a mobile device to communicatepayment information from the payment card to the mobile device. In step2614, a purchase may be completed by a mobile device by communicatingreceived payment information to network entities to settle a paymenttransaction.

Process sequence 2620 may, for example, autonomously detect that apayment card is in a touching or a proximity relationship to a mobiledevice (e.g., as in step 2621). In step 2622, a contactlesscommunication channel (e.g., an RF, capacitive, audible, visible,electromagnetic, or magnetic communication channel) may be generatedbetween a payment card and a mobile device to communicate paymentinformation from the payment card to the mobile device. In step 2623, apurchase may be completed by a mobile device by communicating receivedpayment information to network entities to settle a payment transaction.

Step 2631 of sequence 2630 may include presenting a card to a mobiledevice. A card may, for example, be a powered card or a non-poweredcard. In steps 2632 and 2633, a contactless communication channel may beestablished between a card and a mobile device and information may beexchanged between the card and the mobile device.

A card may, for example, include a near-field communication device(e.g., an RFID) that may communicate with a contactless communicationdevice of a mobile device to form a two-way communication channelbetween the card and the mobile device. A card may, for example, includecircuitry to simulate touch (e.g., a capacitance change) in order toform a contactless communication channel with a mobile device.Accordingly, for example, a card may be pressed against atouch-sensitive display of a mobile device and information may becommunicated by the card to the mobile device through a series ofcard-simulated touches that may be detected by the touch-sensitivedisplay of the mobile device.

A card may, for example, include a light sensor to form a contactlesscommunication channel with a mobile device. Accordingly, for example, acard may be pressed against a display of a mobile device and informationmay be communicated from the mobile device to the card through a seriesof light pulses generated by the display of the mobile device. Afrequency, pulse width, and/or a pulse intensity of light pulses may,for example, be detected by a processor of a card as data communicatedby a mobile device.

A card may, for example, include a light source (e.g., an LED) to form acontactless communication channel. Accordingly, for example, a card mayemit varying light pulses from an LED that may be detected by amotion-capture device (e.g., a camera) of a mobile device as datacommunicated by the card. A card may, for example, include soundemission capabilities that may be detected by a microphone of a mobiledevice as data communicated by the card through a contactlesscommunication channel. A mobile device may, for example, include soundemission capabilities that may be detected by a microphone of a card asdata communicated by the mobile device through a contactlesscommunication channel.

Step 2641 of sequence 2640 may include selecting items for purchaseusing a mobile device. A mobile device may, for example, include ascanning device (e.g., a camera) that may be used by a mobile device tocapture images of barcodes that may be associated with items forpurchase (e.g., grocery items in a grocery store). Accordingly, forexample, a mobile device may collect images of barcodes and a processorof the mobile device may analyze the images to retrieve information(e.g., item description and cost) of each item scanned. Each item'sdescription, cost and other information may, for example, be displayedon a GUI that may be generated by a processor and presented to a displayof the mobile device as in step 2642. A payment card may, for example,be presented to the mobile device (e.g., as in step 2643) and paymentinformation may be exchanged between the payment card and the mobiledevice (e.g., as in step 2644) via a contactless communication channel(e.g., an RF, capacitive, audible, visible, electromagnetic, or magneticcommunication channel). In step 2645, a mobile device may communicatereceived payment information to network entities (e.g., a payment serverand/or an issuer) to complete the transaction.

In step 2651 of sequence 2650, for example, a mobile device may remotelyaccess an electronic bill. For example, a merchant (e.g., a restaurant)may provide access to a bill (e.g., a restaurant tab for food andbeverages) to a patron of the merchant via that patron's mobile device.As per one example, a merchant may provide a link to a bill via amessage (e.g., an email message or a text message) that may be sent bythe merchant to the patron's mobile device or that may be sent by thepatron's mobile device to the merchant. The patron may click on the linkand may be taken to a website that may provide access to the patron'stab via a browser that may be executing on the patron's mobile device.As per another example, a data call between a patron's mobile device anda merchant may execute an application (e.g., locally on the patron'smobile device and/or remotely on a merchant's server) to allow a patronto review his or her bill.

Each item on the patron's bill may, for example, include a description,cost and other information and may be displayed on a GUI that may begenerated by a processor and presented to a display of the mobile deviceas in step 2652. A payment card may, for example, be presented to themobile device (e.g., as in step 2653) and payment information may beexchanged between the payment card and the mobile device (e.g., as instep 2654) via a contactless communication channel (e.g., an RF,capacitive, audible, visible, electromagnetic, or magnetic communicationchannel). In step 2655, a mobile device may communicate received paymentinformation to network entities (e.g., a payment server and/or anissuer) to complete the transaction.

Persons skilled in the art will appreciate that the present invention isnot limited to only the embodiments described. Instead, the presentinvention more generally involves mobile information and the exchangethereof. Persons skilled in the art will also appreciate that theapparatus of the present invention may be implemented in other ways thanthose described herein. All such modifications are within the scope ofthe present invention, which is limited only by the claims that follow.

1. A method, comprising: accessing a network using a mobile device;selecting an object for purchase from said network using said mobiledevice; communicating payment information from a payment card to saidmobile device using a contactless communication channel; andcommunicating said payment information from said mobile device to saidnetwork to complete a purchase transaction for said object.
 2. A method,comprising: communicating source account information to a first mobiledevice using a first contactless communication channel; communicatingtarget account information to a second mobile device using a secondcontactless communication channel; communicating said target accountinformation from said second mobile device to said first mobile device;and coordinating a money transfer from said source account into saidtarget account using said first mobile device.
 3. The method of claim 1,wherein said mobile device is a laptop computer.
 4. The method of claim1, wherein said mobile device is a PDA.
 5. The method of claim 1,wherein said mobile device is a phone.
 6. The method of claim 1, whereinsaid contactless communication channel is an RFID communication channel.7. The method of claim 1, wherein said mobile device and said paymentcard are brought within a proximity distance of up to two inches toestablish said contactless communication channel.
 8. The method of claim1, wherein said payment card is a powered card.
 9. The method of claim1, wherein said payment card is a non-powered card.
 10. The method ofclaim 1, wherein said payment card simulates a series of touches to adisplay of said mobile device to establish at least a portion of saidcontactless communication channel.
 11. The method of claim 1, whereinsaid mobile device communicates an optical data stream to said paymentcard to establish at least a portion of said contactless communicationchannel.
 12. The method of claim 2, wherein a powered card communicatessaid target account information.
 13. The method of claim 2, wherein anon-powered card communicates said target account information.
 14. Themethod of claim 2, wherein a powered card communicates said sourceaccount information.
 15. The method of claim 2, wherein a non-poweredcard communicates said source account information.
 16. The method ofclaim 2, wherein said first mobile device is a laptop computer.
 17. Themethod of claim 2, wherein said first mobile device is a PDA.
 18. Themethod of claim 2, wherein said first mobile device is a phone.
 19. Themethod of claim 2, wherein said second mobile device is a laptopcomputer.
 20. The method of claim 2, wherein said second mobile deviceis a PDA.
 21. The method of claim 2, wherein said second mobile deviceis a phone.